---

---

• Email Basics
• Email Construction
• Signature
• Body
• Header
• Bounces
• Using Email Programs
• Reading Email
• Navigating and Managing Email
• Replying to Email
• New Email
• Finding People
• Friends
• Acquaintances
• Mailing Lists
• Moderated vs. Unmoderated
• Individual Messages vs. Digests
• Mailing List Managers
• Using LISTSERVs
• Using ListProcessor
• Using Majordomo
• Neither Rain, Nor Snow...

Electronic mail is the most pervasive application on the Internet, and for good reason. What better way to communicate with so many people so quickly? But to use and understand email properly, I must show you how it's constructed, the relevant social mores and pitfalls, and how you can use it.

What makes up an email message? Most messages have two important parts, with a third part that doesn't have to appear. The first two parts are the header and the body of the message, and the third, non-essential part, is the signature. For simplicity's sake, let's work backward.

Signatures are just about what you'd expect -- some text that goes at the bottom of every message you send; many email programs, including Eudora, which I've included on the ISKM disk, provide a facility for creating signatures. Most people include their names (real or pretend) in their signatures; it's considered good form to include your preferred email address in your signature as well, just in case the address in the header isn't useful for some reason or another. After you get past the basics of name and email address, however, you can put anything you like in your signature. Many people lean toward clever quotations or manage to express some sporting partisanship of their favorite team, usually with an erudite "Go Weasels '95" or some such. (It's hard to grunt in ASCII.) I prefer clever quotations, especially so if changed once per day -- not that I have time or energy to think them up or type them in every day. Here is a signature that must have taken some time to create, because all the lines and dashes had to be typed in the right place:

/=====================================================================\
||   _                                                                ||
||  *  \          Sorry, a signature error has occurred.              ||
||     _|_                                                            ||
||   /     \      /============\          /===========\               ||
||  |       |     |   Resume   |          |   Restart |               ||
||   \ --- /      \------------/          \----|\-----/               ||
||                                             |  \                   ||
 \=============================================|   _\==================/
                                               |/\ \
                                                  \_\

Many people also use signatures to disclaim their messages. The signature acts as a disclaimer, usually stating that the opinions and facts stated in the preceding message have no relationship to the organization paying for the account or employing the individual. Disclaimers are important online because readers have no context in which to take postings. If Ferdinand the Bull posts a glowing review of specific species of cork tree, for example, he should also note at the bottom of his review that he is a paid consultant of Corking Good Times International, and is therefore biased. More common are glowing reviews from users who "have no relationship with Corking Good Times International, other than as a satisfied customer." Disclaimers also serve to ensure that no one takes the words of a single employee as the policy of the entire organization. Marketing departments hate that. "But Joe said online that Apple was going to give free Macs to everyone whose birthday falls on the second Tuesday of odd months this year." "Yeah, sure buddy."

One warning, though. Mailing lists that are published as digests -- that is, lists in which a moderator collects the day's messages and concatenates them into a single file -- frown on or even reject postings with multiple line signatures. This suggestion makes sense, if you think about it. A large digest file can have 50 messages in it, and if every person has a four-line signature, the digest suddenly becomes 200 lines longer than necessary. But enough about signatures, let's look at the meat of the message.

What you put in the body of your letter is your business. I can recommend several practices, however. First, get in the habit of pressing the Return key twice between paragraphs to insert a blank line between them; that additional white space makes email messages much easier to read. Nothing is harder to read than page after page of unbroken text.

Actually, something is worse than unbroken text, and that's page after page of unbroken text in capital letters. DON'T USE ALL CAPS BECAUSE IT LOOKS LIKE YOU'RE SHOUTING! No one uses all capital letters for long because everyone hates reading it and will tell you, nicely the first time, to stop.

I suppose now is a good time to talk about manners in terms of the sorts of things you should consider when writing email. Email differs from normal mail in many ways. Think of the difference between a short note to your mother, a memo at work, and a formal business letter. Most email falls somewhere between the short note and the memo, and seldom do you ever see an email message with the formality and rigidity of a business letter. Although I'm giving this information in the context of email, it applies equally as well to postings on Usenet; so if you like, reread this section, substituting posting for email everywhere.

How do you start these messages? In many ways, email acts as the great equalizer. Most of the time, you know someone's name and email address when you send email to him, nothing more. joeschmoe@alien.com could be a janitor, a summer intern, or the president of a Fortune 500 firm. Similarly, any address ending in edu can link to a student, some member of the staff, a world-renowned professor of underwater basket weaving, or the president of the university. You have no way of knowing, unless that fact somehow comes up in conversation.

Most people react to this lack of context by treating everyone with the same level of polite, but informal, respect. Seldom do people use their titles, so equally seldom do correspondents use those titles in email. Everyone is on a first-name basis. I once took a class with the astronomer and science advocate Carl Sagan while I was at Cornell, and the first day of class, an awed undergraduate (but braver than the rest of us) asked, "How should we address you, Dr. Sagan?" He replied, "You can call me Mr. Sagan, Professor Sagan, Dr. Sagan, or Herr Doktor Professor Sagan," he paused, "or you can call me Carl." Carl it was then, and the class benefited greatly from that level of informality, just as the Internet does.

In light of this knowledge, when I started using email I thought about the differences between email and paper mail (hereafter called by its true name in the Internet community, snail mail). The standard salutation of "Dear" sounds inappropriately formal and stilted to my ears (apologies to Miss Manners). Since email more closely resembles spoken communication than written, I opted for the less formal and more colloquial "Hi," which has served me well. Some people forego the salutation completely, relying solely on the first name, but that approach feels abrupt to me, as if someone called me on the phone and stated my name without a "Hello" or so much as a questioning tone. Do what you like, though; no one has laid down rules on this matter.

What you say in the letter itself deserves more thought, however. Because email is so quick and it's so easy to respond without thinking, many people often reply hastily and less politely than they would had they taken a moment to consider. Remember, you want to achieve a certain effect with an email message, just as you do with any form of communication. If you simply whack your first thoughts into a message, it probably won't properly convey your true feelings. If you want information from someone, phrasing your request politely only increases your chances of getting that information, and if you wish to comment on someone else's words, doing so in a reasoned and level-headed manner ensures that that person won't immediately consider you a serious jerk.

You also must remember that informal though email may be, it lacks most of the nonverbal parts of communication that we seldom consider in normal speech. All inflection, body language, and facial expressions disappear, and it doesn't help one whit if you make them while composing the letter. Email is ASCII text only, and only two ways exist to convey inflections such as sarcasm or irony that would be obvious in spoken conversation. First, polish your writing skills. There is no substitute for clear and coherent writing. Many people find writing difficult, but I recommend that you don't think of composing email as writing, but as speaking to someone who sees your words but cannot see or hear you. Most people who claim they can't write have little trouble making themselves understood when speaking.

Second, utilize smileys, or as they are sometimes known, emoticons. Smileys are strings of punctuation characters meant to be viewed by tilting your head (which is usually easier than tilting your monitor) to the side. (If they still look wrong, try tilting your head to the other side.) People have come up with literally hundreds of different smileys, and you can find lists containing them on the Internet. Seth Godin has even compiled many of them into a book, The Smiley Dictionary, published by Peachpit Press (and there is at least one other book, published by O'Reilly & Associates, on the same somewhat silly topic). I take the view that only two, or maybe three, smileys are at all useful in normal email. The first is the happy face :-), which implies that what you just said was meant as humor or at least shouldn't be taken too seriously. I often use it to imply that I would have said that bit with a smile. A variant of the happy face uses the semicolon instead of the colon ;-) and (because of the wink) implies that the preceding sentence was somewhat sarcastic or ironic. Finally, the frowning face :-( implies that you aren't happy about whatever you just said.

I use smileys relatively heavily in email, where I don't have time to craft each letter as carefully as I would like. I miss not being able to use them (I could, but no one would understand) in snail mail occasionally, and I actively try to avoid using them in TidBITS, favoring instead words that convey my feelings without the smiley crutch. When in doubt, use smileys. If I say in email, "Well, that was a stupid thing to do," the message is much more offensive than if I say, "Well, that was a stupid thing to do. :-)" Believe me, it is.

I may have given the impression that the Internet is this utopia where everyone always behaves nicely and ne'er is heard a discouraging word. Unfortunately, that's not so, and in reality you see plenty of flaming on the nets. Flaming happens when, in a PC discussion list, you innocently mention that you like your Macintosh, and 17 people immediately jump on you in email and pummel you within an inch of your electronic life for saying something so obviously stupid and incorrect when everyone knows that only weenies, wimps, and little wusses use those toy Macintosh computers, which are good only for paperweights -- and expensive paperweights at that, because you can buy three completely configured, top-of-the-line Pentium-based PCs for the same price as a used Macintosh Classic -- without a hard drive. And by the way, did I mention that your mother wears combat boots and your father wears ballet slippers? :-)

The preceding paragraph is flaming (except for the smiley, which I threw in to indicate that I was kidding about your parents' footwear), and if you must respond to an inflammatory message, which I don't recommend, do it in email. No one else wants to read your flames. Think before you lower yourself to flaming; it never solves anything. I have found in almost every case that replying calmly and clearly embarrasses anyone (assuming that person is normal and rational, which is not always a good assumption) so thoroughly that she immediately apologizes for being such a jerk. And yes, I know how hard it is not to just tee off on someone. Restrain yourself and rest assured that everyone who sees your restraint will think more highly of you for it.

Note: My favorite method of responding to long and vitriolic flames is to send back a single-line message reading, "You may be right. -Engst." I heard about this technique in an interview with Tom Brokaw, I think, and it works extremely well, confusing the recipient to no end and generally putting a stop to the flaming.

Often, people flame companies or large organizations that are doing stupid things. Various governments are favorite, though slow-moving and not very challenging, targets. This sort of flaming is more acceptable, although you may start a flame war if other people don't share your opinions on some major topic, such as whether the Mac is better than Windows. As a spectator, you may enjoy watching the occasional flame war, as I do, but again, they never solve anything, and they waste a huge amount of bandwidth (which is composed of transmission time, people time, and disk storage throughout the world).

Note: Actually, I've decided that in some respects a certain amount of flaming can be positive, because there are only three ways of ending an argument on the Internet. Agree to disagree, win your opponent over to your side, or stop from exhaustion. In no case does anyone get knifed or shot, and if participating in a flame war lets someone blow off some steam, that's better than their going home and abusing their children. Everything is relative.

Keep in mind that no matter what you say, it may not be private. Always assume that gobs of people can and do read every message you send. These people include your coworkers, your system administrator, system administrators on other machines through which your email travels, random pimply-faced fools who like poking around in other people's email, and last, but certainly not least, the government, probably in the form of the CIA, FBI, Secret Service, or National Security Agency. I realize this sounds alarming, and it is most certainly not completely true, but the possibility exists for all of these people to read your email.

In reality, email carries significant privacy, but because you have no guarantee of that privacy, you should stay aware of what you're saying. This suggestion is especially true if you use email at work, where you could lose your job over ill-considered remarks in email. It's always a good idea to check on your employer's policy about email privacy.

Note: There have been a number of court cases regarding ownership of email (Does it belong to you? Does it belong to your employer?) at some large companies like Epson and Borland. Since it may come down to a matter of their lawyers being meaner than your lawyers, don't push it.

This lack of privacy carries over to mailing lists and Usenet news (where you want people to read your messages, but you may not want the government to keep tabs on your postings). In fact, some people have gone so far as to include inflammatory keywords in otherwise innocuous postings, just to trip up the rumored government computers scanning for terrorists, assassins, space aliens, nudists, vegetarians, people who like broccoli, and other possible undesirables.

I almost forgot about attachments. Many people like to send each other files in email, and although you can do this by simply encoding the file as BinHex or uucode (I'll talk about these file formats in a few chapters) and pasting it into the body of the message, modern email programs instead enable you to merely attach the file to the message with a specific command.

That's all fine and nice if your recipient also uses an email program that knows how to deal with the attachment, but if not, your friend sees the file, usually encoded in BinHex or uucode, at the end of the message in the body (but before the signature). Large email files can be a pain to deal with unless your email program supports attachments.

Okay, I admit it; I've been avoiding talking about the header so far. I did so because the message header generally looks like a lot of gobbledygook to the novice user, and in fact, it should. The header exists for the computers, not for the users, and you're lucky that you can read it as well as you can. In some programs you can see an abbreviated header, which is good, and in some cases you can ignore the header altogether, which can be a little dangerous because it may not be clear who receives a reply to that message.

As much as the header is technoweenie information that exists primarily for the computers to route mail to you, I recommend that you choose an abbreviated header display if you have one. An abbreviated header shows you information that can be useful, such as who sent the email to you, when it was sent, what the subject of the message is, and to whom it was sent (not always only you -- it's easy to send the same piece of email to multiple people).

Take a look at a typical header, culled just now from one of my archived pieces of email (see figure 7.1).

Figure 7.1: A sample header.

Let's take a spin through all the different parts of the header, explaining each one along the way and starting with the glop at the top.

From TC.Cornell.EDU!baka!mha Mon Jul 19 07:08:08 1993
Received: by tidbits.com (uA-1.6v2); Mon, 19 Jul 93 11:04:17 PDT
Received: from THEORY.TC.CORNELL.EDU by nwnexus.wa.com with SMTP id AA18636
5.65c/IDA-1.4.4 for ); Mon, 19 Jul 1993 08:32:37 -0700
Received: from baka.UUCP by theory.TC.Cornell.EDU with UUCP id AA02180
(5.65c/IDA-1.4.4 for ace@tidbits.com); Mon, 19 Jul 1993 11:32:32 -0400
Received: from BAKA (QM 2.6) by baka.ithaca.ny.us (UMCP\QM 2.1.3)
id AA05891; Mon, 19 Jul 1993 11:32:36 EDT

The preceding lines are merely routing information that tell you where a message went and when it arrived there. You have to read it backwards to follow the flow, so this message traveled from the QuickMail server at BAKA Computers to the UMCP Bridge (baka.ithaca.ny.us), which acts as a gateway for QuickMail messages destined for the Internet. From there it traveled to Cornell's Theory Center, theory.tc.cornell.edu, and from the Theory Center, the message bounced almost instantly to nwnexus.wa.com, which is my Internet host, and then several hours later to my machine, tidbits.com.

You generally can ignore this part of the header, although it can be fun to see where your message went at times. If your message bounces -- that is, if it fails to go through for some reason and comes back to you -- looking at this part in the header helps you determine how far it got and which machine didn't like it. More about how to handle bounces in a bit.

Message-Id: <00192.2825926356.5891@baka.ithaca.ny.us>

The Message-Id line uniquely identifies each message. It's generally of no use at all, and although it looks like an email address, it's not.

Note: Only once have I found the Message-Id information useful. For some reason, one of my hosts was duplicating some files that went out, and often the only difference between the messages was that at a certain point they started having different ids. Unfortunately, I never figured out how to solve the problem; I just switched to another host.

Organization: BAKA Computers Inc.

The Organization line identifies the organization of the sender, as you may suspect. Individuals often have a good time with this line because they don't have real organizations to put down and can thus include fake organizations like "Our Lady of the Vacant Lot Enterprises."

To: ace@tidbits.com (Adam C. Engst),
Rick_Sutcliffe@faith.twu.ca (Rick Sutcliffe)

The To line can have one or more entries, and it specifies, reasonably enough, who the mail was sent to. The recipient may not be you because you might be the person mentioned in the Cc line or even the Bcc line (which you don't see because Bcc stands for Blind Carbon Copy). Most of the time you see a name before or after the email address, but it's not mandatory.

From: mha@baka.ithaca.ny.us (Mark Anbinder)

The From line indicates who sent the email and is self-explanatory.

Date: Mon, 19 Jul 1993 11:08:08 EDT

The Date line lists the date that the email was sent originally, not the time you received it or read it, and should usually indicate the time zone in which the sender lives. Even then I find it difficult to keep track of what time it is in other countries. Do you know the local time in Turkey right now? Some messages use a number, either positive or negative, and the acronym GMT, which stands for Greenwich Mean Time. Unfortunately, this use requires that you know what time it is in Greenwich, England, and that you know how your local daylight savings time is involved. Date lines usually just confuse me.

Note: The best way to determine what time it is in another part of the world is to open the Map control panel, click the appropriate spot on the map of the world, and look at the time display. Finding the appropriate spot is up to you. I hope you paid attention in geography class in grade school.

Subject: Terminal Compromise

The Subject line should give a clear and concise description of the contents of the email message. In practice, this description often isn't true, especially after a discussion proceeds, changing topics occasionally, with everyone using the reply function to keep the Subject the same. After a while the Subject line bears no resemblance to the contents of the message, at which point it's time to change the line.

Cc: werner@rascal.ics.utexas.edu (Werner Uhrig)

The Cc line lists all the people who received copies of the message. There is no functional difference from being on the To line or the Cc line, but in theory if you receive only a copy, the message shouldn't concern you as much. In practice I notice little difference.

An abbreviated header probably just shows these five lines and avoids displaying the routing information at the top of the header.

You also may see other lines in the header that identify which program mailed the message, to whom the recipients should reply, the type of data included in the message, how the data is encoded, and that sort of thing. In general, you don't have to worry about anything in the header very much, but it's worth taking a look every now and then to see if you can tell what's going on in there.

In a perfect world, all email would get through to its destination quickly and reliably. But just as with snail mail, which can take one to five days to appear, and which sometimes never appears at all, email isn't perfect, and sometimes it will bounce back to you. At times the machine that bounced the mail back to you will give you a hint as to what went wrong, but more often you're on your own.

The most common reason for a bounced message is a typo somewhere in the address. That's one reason that short email addresses are good -- they're easier to type and thus less likely to be mistyped. The first thing to do when you get a bounce is to look through the header of the original message (the full headers are usually returned to you) and make sure you typed the address properly. Everyone makes this mistake on occasion.

A common error message in bounced email is "User unknown." This means that the email arrived at the proper machine, which searched through its list of users and decided that it didn't have a user with the name that you used. Again, this is most commonly due to a typo in the userid, although sometimes there are problems on the destination machine that have caused it to forget about a user, possibly temporarily. After checking the address, try resending the message, especially if you've gotten mail through to that address before.

Along with unknown users, you may see error messages complaining about "Host unknown." This is a more serious error that's more difficult to work around if it's not simply a typo. The basic problem is that for some reason one machine, perhaps your host machine or perhaps one further along in the path to the destination, was unable to contact the destination machine. There's not much you can do in this case other than try again a little later, in the hope that the machine you're mailing to has come back up.

One thing to watch out for is that sometimes the header provides an incorrect address to your email program, but the person includes the proper one in their signature. If you have trouble replying to a message, and the address you're replying to is different from an address listed in the signature, try using the signature address instead.

Note: I find this trick especially useful if the address in the signature is simple, whereas the address from the header is long and convoluted. Simple addresses seem to be more reliable, on the whole, although that's not a hard and fast rule.

All email programs share some basic features that you need in order to quickly and efficiently read, reply, and store your email. However, after these basic commonalities, the differences between programs mount quickly, so I concentrate on those differences when I talk about each program later in the book. For the moment, though, let's look at what an email program must do at a minimum.

An email program should enable you to display and scroll through an email message easily. Because you're using the Macintosh, you should be able to do all the standard Macintosh things to text in a window, such as copying and pasting into a different program, resizing the window to display more text, selecting all the text with a single command, and that sort of thing.

Although you usually can choose the font and size in which you view messages in Macintosh email programs, I recommend that you stick to a monospaced font such as Monaco or Courier. People on the Internet must format tables and graphics with spaces, and monospaced fonts such as Monaco and Courier display these tables and graphics properly. Proportionally spaced fonts such as Times and Helvetica don't work as well because the characters in these fonts can have different widths, with a lowercase i being thinner than an uppercase W. Few of these features are generally available with a Unix mail program; that's one of the major advantages of using the Mac.

Note: Some email or communications programs come with special monospaced fonts that are supposedly easier to read than the standard Monaco and Courier. If you see fonts like TTYFont, VT100, or Mishawaka, they're designed for displaying Internet email on the screen. I personally prefer Monaco 9 point.

Another important feature of an email program is the manner in which it enables you to move between messages, save messages in different mailboxes, and delete unwanted messages after you've read them. Most email programs display a list of the messages in an In Box area, and some indicate which messages you have already read, replied to, or saved to disk. Opening a message usually opens a new window to display the message, and sometimes closing the window (with or without deleting the current message) opens the next unread message -- a nice feature for those who receive a great deal of mail. Being able to sort the list of messages is useful, and you should be able to select multiple messages at once to move them to another mailbox or delete them.

Note: Some of these navigation features may not exist in the email program you use, but with a macro program like CE Software's QuicKeys, you may be able to simulate them.

Speaking of multiple mailboxes, all email programs should support them, though unfortunately not all do. Most people want to save some of the messages they receive, so a program should allow you to create your own mailboxes for filing away messages on different topics. Of course, if you can create a new mailbox, the email program should enable you to do everything you can do in your In Box to the messages stored in a personal mailbox.

Note: Perhaps the worst, and most surprising, offender in the multiple mailbox world is Apple's PowerTalk (released in late 1993), which puts a single mailbox on your Mac's desktop, but loses mail-related information like sender, subject, and date if you copy the messages out of the mailbox to a folder.

While you're managing your email, you will undoubtedly want to delete many of the messages you receive. This area may seem straightforward, but the better email programs follow Apple's lead with the Finder and enable you to trash a file without actually immediately deleting it. The easier it is to delete a message (and it should be very easy since you're likely to eventually want to delete most of the mail you receive), the more likely you will eventually delete something accidentally. If the email program deletes immediately, your message is toast. The other advantage of the two-stage (where a message is put in a trash can before being deleted later) or a delayed delete (where a message is marked as being deleted but isn't actually deleted until you close the mailbox) is that you then don't have to put up with an annoying confirmation dialog box every time you delete a message.

Some of your messages may, in fact, contain programs or other files that you want to save to a normal Macintosh file. A few email programs automatically detect attachments encoded in certain formats (more about file formats later) and decode such messages on their own. But one way or another, you need a simple way to save the message you're looking at without copying and pasting the entire thing into a word processor.

Much of the mail you receive requires a reply of some sort, so an email program should make replying extremely easy, either with a command key shortcut or a single click on an icon. An email program also should facilitate quoting the original message, or prefixing each line with one or two special characters, usually a greater-than symbol and a space. Using quoting, you can easily include some of the message you're replying to so that the recipient has some context to know what you're talking about. A nice feature is the ability to select just a certain part of the original message and have the email program quote only that selected text in the reply and ignore the rest of the original message (see figure 7.2).

Figure 7.2: Original text and quoted text.

Note: Rick Holzgrafe has written a clever little $10 shareware utility called SignatureQuote that enables you to quote messages properly even if your email program doesn't support it. SignatureQuote supports two quoting styles, two signatures that you can paste in, and can join and split text. It's a must-have if you're locked into a lousy email program. It's in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/

Because an email message may have originally been sent to several people, an email program should give you the option of replying only to the sender or to all the people to whom the message was originally sent. At the same time, it ideally should make sure that you see the salient lines in the header. I've spawned a couple of embarrassing scenes by forwarding a message to a friend, and when my friend replied to me, his email program saw that mine had included the original message's address in the Reply-To line in the header. So his reply, instead of going just to me, went back to the sender, which was a mailing list that went to thousands of people. Oops! Luckily, I didn't say anything embarrassing and neither did he, so we were safe, but that's a good example of how two computer professionals who know better could have been thoroughly embarrassed in public. Think of this situation as standing up in a crowded restaurant and shouting loudly that your underwear has holes. You get the idea.

More powerful email programs provide features that can automatically mark or reply to email based on the contents of the header or the body of the incoming message. They often generalize these features so that you can essentially run a mailserver, which sends out requested information automatically via email. You also can use this sort of feature to run a simple mailing list, which takes a message to a certain local address and forwards it automatically to a list of subscribers.

Note: There are several programs that enable you run your own mailing list from a Macintosh and do things like auto-replies, although they currently require a direct connection to the Internet. Look for MailShare and AutoShare in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/tcp/mail/

When replying to email and when creating new mail, an email program should provide all the features that you're used to when you're writing in a Macintosh word processor. In my opinion (which is by no means universal), the standard editors in the character-based Unix world stink (yeah, I know those are fighting words), and I spend so much time writing and editing my email that I couldn't possibly put up with anything other than a decent Macintosh editor. However, because every email program implements text entry and editing on its own, none of them compare to a full-fledged word processor, and a few barely even compete with the free TeachText or its fancier successor, SimpleText. My dream, which isn't all that far off, is to be able to use Nisus Writer, the word processor with which I'm writing this book, for all of my email. With the growing acceptance of Apple events, this change will happen. I just hope it happens sooner rather than later.

I may be odd in this respect, but I think that any email program should make it easy to save a copy of everything you write, preferably automatically. I send more email than most people, often as many as 1,000 messages per month, but I like to be able to go back on occasion and see what I said, forward a message to someone who lost it, or just browse through the thoughts that appeared in my writings at that time. Why bother to keep a diary if you're writing about most of what happens in your life in email to friends?

Finally, whenever you create email, your email program should enable you to send the mail to a nickname or alias, which is merely another, easier-to-remember form of an email address. So instead of typing ferdinand-the-bull@cork.tree.com every time you want to send that person email, you can type the shorter Bull. Be careful with nicknames because it's easy to create more than you can easily remember, at which point they don't particularly help any more. Defining nicknames for everyone you might ever send email to is a waste of time; settle for defining a nickname only after you decide that you are likely to send that person email frequently.

Note: You want to be slightly careful with nicknames, because occasionally the recipient sees the nickname as well as the address. A friend once created a nickname DA BOSS for our supervisor, who thought it was funny when she saw it. I could think of some less humorous situations.

Now you know how an email program should work and how to read email addresses when you see them littering up this book and the nets in general. But how do you find people to write to? Finding people to write to depends on what you're looking for. Hmm? What does he mean by that?

Assume that there are two types of people -- those you already know and those you haven't yet met. The latter group makes up most of the world, and in some respects, they are the easiest to find and talk to because you don't really care who specifically you end up talking to. After all, you don't know any more about one stranger over another, so who you talk to makes no difference.

When I first started using the networks way back when, few of my friends had accounts, and of them, only my best friend from high school ever managed to send me email more than once. I think I got a total of three messages from him. I tried to convince them, but I just couldn't get my friends to use email. Finally, I decided they all truly hated me (a logical conclusion for a 17-year-old college freshman) and gave up on them. My ego has recovered some since then, because I've found that convincing people to start using email just to talk to me is almost impossible. This argument worked with my parents, after a while, especially after my sister also started using email heavily at Cornell. But otherwise? I can't think of a single person whom I've convinced to use email for my sake, although we recently managed to set my grandmother up with an old Macintosh Classic and an email account. The moral of the story is that you should assume that you can talk only to people who already use email.

Okay, so once past that reality check, how do you find the address of someone who you know uses email? The simplest and most effective method seldom occurs to many net denizens -- use the telephone and ask them. This method, low-tech though it may be, has the advantage of being quick, accurate, and easy. Of course, it does ruin the surprise value of that first email note. Such is life. You do need to know your friend's telephone number, or failing that, her address so you can call the all-knowing information computers at the phone company. If you don't even know where your friend lives, she may be trying to hide from you anyway after that ugly incident a while back.

"Aha!" you say, "If the all-knowing phone company computers can give me my friend's telephone number, aren't there all-knowing computers on the Internet that can give me my friend's email address?" Nice try, and good question, but the answer is, unfortunately, maybe. Some computers know what users they support, and you can find some information via services called Finger, Whois, X.500, Ph, Knowbot, and various others, but that information doesn't help unless you already know what machine to search. Several attempts have been made at linking various directory services on different machines, but I've never found them to be the slightest bit useful. The problem is twofold. First, hooking a local directory of users to an Internet-wide directory requires some effort and certain standards, and inertia being what it is, that effort isn't always made, and the standards don't exist. Second, many organizations shield their users from the outside world for reasons of security and privacy. These shields also make it difficult to determine how many people actually use the Internet because one domain may have two users, like tidbits.com, or many thousands of users, like microsoft.com.

Note: Frankly, because I find these services so completely useless, I'm not going to bother to discuss them further. That said, if you crave some frustration, go to the University of Minnesota's Gopher server at gopher.tc.umn.edu (the Home Gopher server by default, if you use TurboGopher), select Phone Books, and then check out the various different options available for searching for Internet email addresses. If you know the organization in question, and they have a Phone Book server, that's the best start -- otherwise you're on your own. The main thing you miss via the Gopher route is the Knowbot Information Service. To access it, telnet to info.cnri.reston.va.us 185 and type help to see the possible commands.

As I said earlier in this chapter, finding new friends is easy on the Internet. You don't know people beforehand, so communicating with them in a discussion list via email or news requires nothing in terms of opening lines or trivial small talk about the fallibility of weather forecasters. If you have something to contribute to a discussion, or perhaps if you merely want to make a private comment to one of the people in the discussion, meeting him is as easy as replying to his message. Whether that first contact grows beyond a one-time message depends on many variables, but with so many people, finding correspondents on the net doesn't take long.

As much as meeting people may be easy, finding them again after some time often proves more difficult. You may not remember where a person lives, if you ever knew, and if it's in the United States at all; you probably don't know his telephone number; and frankly, you may not even remember how to spell his name. And yet, all too often I've had long, involved conversations that eventually trail off after several weeks or months, and then I don't hear from that person again. If I haven't saved a message (which contains the all-important email address in the header) or recorded his email address somewhere, I have to hope that my friend has better organizational systems than I do.

I suggest that you figure out some way to keep track of your correspondents' email addresses. Nickname features work well although they may prove unwieldy as a storage mechanism later on. If that's true, I recommend using a standard database or address book program that can handle extra fields for email addresses. This advice may sound obvious, but I can't tell you how many times I've lost an address that I wanted several months later. These days I keep a copy of every piece of email I send, in part so I can search that file, large though it may be, for email addresses that have escaped my short-term memory.

There's no accounting for taste, and similarly, there's no accounting for different interests. I may be interested in electronic publishing, tropical fish, and competitive distance running, whereas the next person might favor The Simpsons, aviation, and Irish culture. As a result, discussion groups have sprung up around almost every imaginable topic, and if your area of interest isn't represented, it's not too difficult to start your own group. These groups take two forms: mailing lists and Usenet newsgroups. I talk more about Usenet in the next chapter; for now I'll concentrate on mailing lists.

The beauty of mailing lists is that they cover specific topics and they come straight to you, without any extra work on your part. If you find yourself interested in a topic, you can subscribe to the appropriate mailing list, and all the traffic comes directly to your electronic mailbox. This system makes participating in many mailing lists easy, even if you have only email access to the Internet; Usenet access may require more money and effort. Luckily for those of you who cannot get Usenet access, many mailing lists and newsgroups mirror each other.

Mailing lists have several other advantages over Usenet news. Email is ubiquitous on the Internet, whereas access to news is far less common (although certainly widespread). Because of the way Usenet news propagates throughout the nets, mailing lists often arrive faster than any given posting in a newsgroup. Because mailing lists arrive in your electronic mailbox, they may seem less intimidating than large newsgroups with many participants. And frankly, many of us who lead busy lives find mailing lists easier to keep up with because we don't have to run another program to read the list, whereas reading news always requires leaving that ubiquitous email program and running a newsreader.

There are a number of programs that operate mailing lists, the most well-known of which are LISTSERV, ListProcessor (also known as listproc), and Majordomo. They all support similar commands; I'll get into those in a moment. LISTSERV is a commercial program from Eric Thomas of LSoft. It currently requires an IBM mainframe running VM/CMS (although versions for VMS, Unix, and Windows NT are in the works). The Unix-based ListProcessor comes from Anastasios Kotsikonas and is now owned by CREN (remember them from chapter 4?). The Unix-based Majordomo is free as far as I can tell.

There also are many mailing lists that are run through hacks to the Unix mailer software -- these generally require some sort of human intervention for subscribing and signing off, although sometimes they use non-standard commands that do the same thing. Have I mentioned yet that I dislike programs that don't work in standard ways? They make life even more confusing than it already is.

Note: You may wonder why LISTSERV doesn't have an E at the end and why it is spelled with all capitals. LISTSERV software has existed for some time on IBM mainframes that run the VM/CMS operating system. This operating system limits userids to eight characters (hence the missing E), and because the operating system itself was originally not case sensitive, all commands and program names have traditionally been typed in uppercase only. The name also may have had something to do with early computer terminals not supporting lowercase, but I can't prove that theory. Just believe me -- by convention, LISTSERVs are always addressed in the uppercase, although it doesn't matter any more.

Along with the different mailing list manager programs, you may have to deal with two other variables related to mailing lists -- moderation and digests. Each of these possibilities slightly changes how you interact with the list, so let's look at each in turn and then go over the basics of using the list manager software as a subscriber.

I suspect many mailing lists started out unmoderated, which means that anyone was able to send a message on any topic (whether or not it was appropriate to the group) to the list. The list software then distributed that message to the entire list. You see the problem already -- no one wants to read a bunch of messages that have nothing to do with the topic or discussion at hand. Similarly, if a discussion is spinning out of control and turning into a flame war, it's just a waste of time for many people.

Thus was born the concept of the moderated mailing list. To stem inappropriate postings, a moderator reads all the postings before they go out to the group at large and decides which are appropriate. Moderated groups tend to have less traffic, and the messages that go through are guaranteed by the moderator to have some worth. This system is good.

Note: The Info-Mac Digest is a prominent example of a moderated group in the Macintosh world. Although they're usually fairly lenient, moderators Bill Lipa, Gordon Watts, Igor Livshits, and Liam Breck do an excellent job, and their efforts are much appreciated by all. I help out somewhat with Info-Mac, although with the files stored on the Info-Mac Archive, not with the Info-Mac Digest itself.

On the downside, moderated groups occasionally run into sticky issues of censorship because the moderator may not always represent the views of the majority of the readers. Moderator positions are volunteer only; I've never heard of a mailing list that elected a moderator, although it's certainly possible, particularly among lists that carry traffic associated with a professional organization.

There's a slightly different form of moderation practiced on some other lists that you may be interested in, such as the Apple Internet Users and Apple Internet Providers lists. Run by Chuq von Rospach of Apple, these lists employ a "List Mom" form of moderation, which means that although all postings appear whether or not Chuq approves, he reserves the right to tell people to take off-topic discussions elsewhere. Since I was about to start similar lists when Chuq created the Apple Internet Users and Providers lists, I volunteered to be an Assistant List Mom on Chuq's lists, which means I help steer the discussions so that they stay on track. Needless to say, I recommend both lists highly for discussions about the Mac and the Internet.

Note: To subscribe to the lists, send email to listproc@abs.apple.com and in the body of the message (the Subject line can be blank or nonsense), put subscribe apple-internet-users Your Full Name or subscribe apple-internet-providers Your Full Name.

Once your subscription has been processed, you will receive an informational file from the list, and then you can start posting questions and helping out with answers that you know. You cannot post to the list until you have subscribed.

I see no reason to choose to read or not read a mailing list based on its moderation until you've spent a while seeing what goes on in the group. I subscribe to various lists, some moderated, some not, and on the whole, both have their place. Keep in mind, though, that if you post to a moderated list, the moderator may reject your posting. Don't feel bad, but do ask why so that your future submissions stand a better chance of reaching the rest of the group. On the other hand, when posting to an unmoderated group, try to stick to appropriate topics because people hate hearing about how you like your new car in a list devoted to potbellied pigs. Too many misdirected postings to a list may agitate list members to the point of asking for a moderator to limit the discussion.

When the number of messages in a mailing list increases to a certain level, many lists consider creating a digest version of the list. A digest is simply a single message that contains all the individual messages concatenated in a specific way. Why bother with a digest? Depending on how your email program works, you might find it awkward to receive and read as many as 30 messages a day, especially if your email service, such as AppleLink, charges you a per-message fee to receive email. Just think how many messages you may have waiting after a week of vacation. If the messages are sent in digest form, a mailing list becomes easier to handle for some people because you get one big message instead of lots of little messages.

Unfortunately, digests have problems too. Some email gateways to commercial services (again AppleLink) limit the size of incoming email messages. Thus, digest mailing lists like the Info-Mac Digest, one of the most popular Macintosh mailing lists, can range in size from 30K to over 100K, so very few issues of the digest sneak through the gateways with size limitations. In addition, you may find it easier to read (or skip through) small individual messages, whereas scrolling through a 100K file can take quite a bit of time and can be extremely awkward with some email programs. To add to the complication, certain email programs can break up a digest into its individual messages for easier viewing. I'm talking the email equivalent of digestive enzymes here.

You must decide for yourself whether a digest is easier or harder to work with, but only with some groups do you have any choice. The LISTSERV and ListProcessor software sometimes provide an option that you can set to switch your subscription to a mailing list from individual messages to a single, usually daily, digest. I don't believe you can toggle this option for Majordomo-based lists, but Majordomo list administrators can set up a separate list that sends out a digest -- you would simply subscribe to the separate (digest) list instead. These separate digest lists in Majordomo generally have "-digest" appended to the listname.

Mailing list managers sport many sophisticated features for managing large mailing lists, and these features have made the programs popular among the people who start and run mailing lists (you didn't think lists just worked on their own, did you?). For instance, you can easily and automatically subscribe to and sign off from mailing lists run with a mailing list manager without bothering a human (in most cases). This significantly reduces the amount of work that the list administrator has to do. These programs generally also have provisions for tracking the subscribers to a list, and for those who want to remain unknown, concealing certain subscriptions.

Mailing list managers can prevent unauthorized people from sending messages to the list. The TidBITS list works this way in theory because only I can send a message, in this case an issue of TidBITS, to the list. I say "in theory" because in practice the safeguards have broken down twice, resulting in confusing messages going to the entire list. The LISTSERV that runs the TidBITS list also knows to route all replies to postings on the list to me directly, which is normally good, but when these two accidental postings got through the safeguards, I received hundreds of messages from confused readers who didn't know why they had gotten this message. It was a major hassle.

The LISTSERV software knows about other LISTSERVs running on other machines around the world and uses this knowledge to limit network traffic. For instance, I send a single message from my machine to a mainframe at Rice University in Texas that runs the LISTSERV handling the TidBITS list. Once the message arrives at Rice, the LISTSERV software checks to make sure it came from me and then sends it out to the many thousands of readers on the TidBITS subscription list.

The LISTSERV is smart, however. It doesn't blindly send out thousands of messages, one per user, because that would waste network bandwidth, especially on expensive trans-oceanic links. Instead, the LISTSERV determines how to enlist the help of certain other LISTSERVs running around the world. If it knows of a LISTSERV site in Australia, for instance, it sends a single copy of the message to Australia along with the list of Australian readers to distribute to. If 100 people in Australia subscribe to the TidBITS list, only one message crosses the Pacific instead of 100 identical copies of the same message. That's elegant.

I gather that ListProcessor and Majordomo, Unix mail-based mailing list managers, don't have as many features as the LISTSERV software, but that's more from an administrator's point of view. Users generally shouldn't care which they use. Don't worry about it one way or another; you have no choice when picking mailing lists to subscribe to. And despite the added features of the LISTSERV software, the thing that makes the administrative details of a list easy to deal with is the administrator, not the software.

Note: ListProcessor used to be called Unix-Listserv and was distributed freely (version 6.0c is still free, even now that CREN has bought it and will be selling future versions), but after some unpleasantness regarding the term "Listserv," Anastasios Kotsikonas decided to rename it to avoid confusion. So, if you see references to Unix-Listserv, they're talking about ListProcessor.

Most people find dealing with LISTSERVs quite easy; however, you should watch out for a few common pitfalls while working with LISTSERV-based mailing lists. Many of the following commands and pitfalls apply to lists run by the other mailing list managers as well, so it's worth reading through the LISTSERV section even if, for instance, you're dealing with a ListProcessor list.

Every LISTSERV list has two email addresses associated with it: the address for the LISTSERV itself, and the address for the mailing list. Why the dichotomy? Well, the LISTSERV address handles all the commands, things such as subscriptions and requests for lists of subscribers and the like. The mailing list address is where you send submissions to the list, assuming of course that it's that sort of list. Here, I use the TidBITS list as an example for my illustrations of the basic tasks you do with a LISTSERV-based mailing list. (The only difference between the TidBITS list and many others is that if you send mail to the mailing list address, it doesn't go to everyone else on the list because the TidBITS list is dedicated to distributing TidBITS, not to discussion, as are most lists. Any mail sent to the mailing list address comes to me, which is fine, because such messages are usually comments on articles.)

If you want to send the LISTSERV that handles the TidBITS list a command, such as your subscription request, send it to listserv@ricevm1.rice.edu. Notice that nowhere in the address is TidBITS mentioned, which is a hint that you have to specify TidBITS somewhere else. LISTSERVs ignore the Subject line entirely, so don't worry about filling it in at all. In the body of the message, though, you can put one or more commands, each on its own line.

To subscribe to the TidBITS list, you send the preceding address a message with the following command on one line in the body of the message: SUBSCRIBE TIDBITS your full name, where you replace your full name with your real name, not your email address or some cute nickname. If the list administrator has to contact you about a problem, she probably doesn't appreciate having to address you as "Dear Swedish Chef Fan Club Ork Ork Ork." To clarify the preceding command, to subscribe to any LISTSERV mailing list, you send the SUBSCRIBE command, a space, the name of the list you want to subscribe to, a space, and then your full name, which must be at least two words. I don't know how rock star types like Cher or Prince manage with LISTSERVs, although I did once get mail from someone who really only had one name. I advised him to use "No really, I only have one name" as his last name. See figure 7.3.

Figure 7.3: Subscribing to TidBITS.

Note: Prince has legally changed his name to a single character that looks like a little stick figure person. Such characters are called dingbats in the publishing world, so I vote that we simply refer to Prince as Dingbat, or perhaps Prince Dingbat to be unambiguous. Needless to say, there's no way to subscribe to a mailing list using a single non-alphabetic character as your name.

The LISTSERV always returns a welcome note after you have subscribed successfully. Keep that note! It lists various useful commands, such as how to sign off from the list, and it usually provides the address of the list administrator. You can contact the list administrator to handle any problems that the automated program chokes on.

You know what I just said about keeping the welcome message from the LISTSERV. Well, I really mean it! I can't tell you how irritating it is to have someone post the list asking how to signoff when it would have been trivial if they'd just kept that welcome message. Actually, I can tell you how irritating this is, because after the 10th or 100th person does, it's tremendously exasperating! Sorry, I'll quiet down now.

After you have subscribed to a list, you mainly want to read messages (which is easy) and post occasional messages to the rest of the people on the list. Once again, to post a message you send it to the mailing list address, which is always the name of the list at the same machine. If, for example, you want to send mail to the TidBITS list (which comes only to me), you send the email to tidbits@ricevm1.rice.edu. I realize I've almost beaten this particular horse to death, but I can't emphasize enough the difference between the LISTSERV address and the mailing list address. You send commands to the LISTSERV, and submissions to the mailing list address. Perhaps the most common problem I see on LISTSERV mailing lists is that people forget to send commands to the LISTSERV address and instead fill up the mailing list with the electronic equivalent of junk mail that no one wants to see. And, of course, sending commands to the mailing list address isn't just annoying and flame-provoking, it's futile because the LISTSERV doesn't respond to them there.

After you've been on a list for some time, the LISTSERV may ask you to confirm your subscription. I set this option with the TidBITS list to clean the deadwood from the list every year. Students graduate, employees move on, bulletin boards close up, and those addresses don't always go away, so the LISTSERV wastes network resources sending to a non-existent person. It's much like talking to a politician. After you have received TidBITS for a year from the LISTSERV, it sends you a message asking you to confirm that you still want to get the newsletter. If you don't respond within seven days, the LISTSERV removes you from the list, assuming that you don't want to continue receiving email from it. If you respond, you must respond with a command so that you send it to the LISTSERV address, not the mailing list address. The command is simply CONFIRM TIDBITS (or the name of whatever list you are asked to confirm).

A portion of the time this confirmation process fails. As I'm sure you noticed in the preceding paragraphs, nowhere do you provide your email address to the LISTSERV, which is supposed to determine it from the header of your message. This idea seems excellent at first because the header should, in theory, have your email address correct, and it doesn't suffer from typos or simple human mistakes that you make if you type it in by hand. However, depending on the routing that your mail takes and how you or your system administrators have your system set up, your address as it appears in the header may change from time to time. Those changes play havoc with the LISTSERV, which is a very literal program. Therefore, when you confirm a subscription, if that confirmation comes from an address the LISTSERV doesn't recognize, poof, it doesn't work. You probably still receive mail to the original address just fine because the address is usually merely a variant on the theme, so many people sit helplessly by as the LISTERV asks for confirmation, rejects it, and then calmly deletes them from the list.

Note: This situation is a perfect example of why computers should never be given direct control over human lives. If you don't properly match for some reason, you're just another file to be deleted.

There is a simple fix. Just resubscribe as soon as the LISTSERV sends either the confirmation rejection or the message saying that it has deleted you from the list. You may get duplicates of everything for a few days, but then the LISTSERV deletes your old address and continues to send to your new one.

If you blow it and misspell your name while subscribing, or perhaps decide to change your name for one reason or another, you can always change your name (only) with the LISTSERV by sending another SUBSCRIBE command. The danger here, as discussed in the preceding paragraphs, is that if your address looks at all different from when you originally subscribed, the LISTSERV happily adds you to the list again, and you receive duplicates of everything. Now is a good time to ask the list administrator for help because the LISTSERV recognizes only your new address, so you can't delete your old address. Bit of a Catch-22 there.

This Catch-22 can apply to trying to sign off from a list normally, as well. Under standard circumstances, if you send the command SIGNOFF TIDBITS to the LISTSERV address, it removes you from the list. If your address in the header has changed, however, it doesn't recognize you as a current subscriber and thus doesn't let you sign off. Once again, if you need help beyond what the LISTSERV program can provide, don't hesitate to ask the list administrator, but ask nicely. These people don't get paid to take abuse, and in fact, they don't get paid to administrate a list at all. I'll tell you how to contact a list administrator in a moment.

The reason for this seemingly irritating address feature is that administrators realized early on that it would be way too much fun to sign someone else up for mailing lists if you really don't like him. You could, for example, sign him up for all the special offers in the back of The National Enquirer. Some friends of mine once had a war with that game, but one was declared the loser when he received bronzed baby shoes and a free subscription to a white supremacist newsletter, or some such nonsense. I'm sure it would be great fun to sign Bill Gates up for a really far-out mailing list, but it gets old after a while and is generally considered abuse of the networks.

Note: Some LISTSERVs can send you files if you send them proper commands in a message. The LISTSERV at Rice, listserv@ricevm1.rice.edu, is one of these sites. In fact, it stores Macintosh files that also exist on the popular FTP site sumex-aim.stanford.edu. You can find site-specific information by sending a HELP command to any LISTSERV, and for the standard LISTSERV information, send INFO REFCARD.

LISTSERVs support a number of other commands, of which only a few are generally useful. If you want to see a list of all the people who have subscribed to a LISTSERV list, you can use the REVIEW command, although many lists no longer return the full list of subscribers to protect against abuses.

The other utility of the REVIEW command is that it includes the address of the list administrator at the top, so it's a good way to find out who to ask for help. Using the REVIEW command is a good way to see what address the LISTSERV thinks you used to subscribe and then ask the administrator for help. For just the administrator address, you can change the command to REVIEW SHORT

Note: Budding direct marketers should be aware that if you request a bunch of subscriber lists and use them for nefarious marketing purposes, the following will occur: (a) that feature will be immediately turned off, and (b) I will personally lead the flamethrower crews on a mission to turn you into a fine electronic ash. That sort of opportunism doesn't fly on the Internet.

To switch a LISTSERV subscription (you must already be subscribed) from individual messages to a digest format, send the LISTSERV address the command SET listname DIGEST. To switch back to individual messages, send it command SET listname MAIL.

Most of the other commands that LISTSERVs support aren't as interesting, or as much fun to write about, so I'll refrain and let you find them on your own.

Working with a mailing list run by the ListProcessor program is remarkably like working with a mailing list run by the LISTSERV program. The similarity isn't coincidental -- ListProcessor started out as a clone of LISTSERV, not in terms of the code, but in terms of the command structure. Thus, the few differences between the two are minimal, especially in the basic functions.

Just as LISTSERVs have a listserv@domain.name address, ListProcessors are generally referred to as listproc@domain.name, although a number of them may still use the listserv@domain.name address left over from when ListProcessor was called Unix-Listserv. And just as the mailing list itself has a different address from the LISTSERV address, something like listname@domain.name, so too do ListProcessor lists. In other words, the confusing dichotomy between the ListProcessor address and the list address exists, just as it does with LISTSERV lists. You send commands to the ListProcessor address (in the body of the message -- the Subject line doesn't matter) and submissions to the mailing list address. I'm really beginning to feel sorry for this poor horse, since I keep beating it, but I can't tell you how many people fail to understand this basic distinction, and in the process irritate thousands of other people on numerous lists.

To subscribe to a ListProcessor-based mailing list, send subscribe listname your full name to the ListProcessor address. Just as with the LISTSERV mailing lists, replace listname with the name of the list you wish to subscribe to and use your real name in place of your full name. ListProcessor figures out your email address from the header of the message.

You leave a ListProcessor-based mailing list by sending the command unsubscribe listname to the ListProcessor address. The command signoff listname does exactly the same thing. Just like the LISTSERV lists, if your address has changed, the automated process very well may not work, at which point you must talk to the list administrator.

The command to switch a ListProcessor subscription from individual messages to digest format differs slightly from LISTSERV -- send the command set listname mail digest to the ListProcessor address. Frankly, I can't see from the instructions how to switch back to individual messages.

If all else fails, try sending the ListProcessor the help command for a simple reference card that explains the options.

This is getting kind of boring, but Majordomo works pretty much like the other two mailing list managers. There are two addresses -- the Majordomo address to send your commands to (often majordomo@domain.name), and the mailing list address to send submissions to (listname@domain.name). You also may (if they're running a recent version of Majordomo) be able to send commands to listname-request@domain.name.

To subscribe to a Majordomo-based list, send email to the Majordomo address with the command subscribe listname. Majordomo differs slightly from the other two mailing list managers in that you don't have to specify your full name, and if you like, you can append an email address to the subscription command. This enables you to subscribe someone else to a mailing list, which can be handy -- just don't abuse it. The same structure applies to removing yourself or someone else from a list -- send unsubscribe listname to the Majordomo address (signoff listname works as well).

An easier method of subscribing and unsubscribing to Majordomo-based lists is to send email to listname-request@domain.name with either the subscribe command or the unsubscribe command in the body of the message. Since you've made it clear which list you want to subscribe to with the address, there's no need to include it in the subscription command.

Finally, you can send Majordomo a help command to see what other options are available. I always recommend that you do this, just so you know how and so that you see what's possible.

Since you're likely to use email heavily, I hope you've gotten a sense for how it works, the sorts of things you shouldn't do with it, what an email program should do for you, and what it makes possible in terms of mailing lists. There are thousands of mailing lists available on the Internet, and you can find some wonderful discussions. If you'd like to search for a good one, check out this URL via a Web browser:
http://www.nova.edu/Inter-Links/listserv.html

But, enough about mailing lists -- let's move on to the next sort of discussion lists, the Usenet newsgroups.